Traditional transaction-processing software enforces a very rigid set of properties which provide the transactional behavior. These are known as the ACID properties, referring to the initial letters of the four principles of Atomicity, Consistency, Isolation, and Durability.
FIG. 1 illustrates the components of a typical transactional data processing system in accordance with the prior art. An application 10 issues a request to data processing system 20. Data Manager 30 receives the request and maps the request into operations (data 30) necessary to achieve the application's initial request. In a messaging system, such operations may involve PUTs to a queue and GETs from a queue. In a database system, the operations may comprise inserts, updates, and deletes of rows in a table.
Each operation will, at some point in time, be written by the persistence manager 60 to persistent store 70. A transaction comprises a set of operations. When the transaction commits, the persistence manager must ensure that all of the operations comprising the transaction are stably recorded or “hardened” to the persistent store. This means that the system can guarantee to the application that it is possible to recover that set of operations in the event of a system failure. In other words, whilst the persistence manager is permitted a degree of flexibility about when to harden the persistence records describing the operations comprising a transaction, all such operations must be on disk by the time the commit is hardened. At this point, the data processing system 20 returns control to the application 10 and processing can continue. In this way ACID properties for each transaction processed by the data processing system can be guaranteed. The provision of ACID guarantees for each transaction can however slow system performance, especially when data items being processed by the system are short-lived and throughput is high. Thus, particularly in the sphere of commercial messaging, it is sometimes acceptable to relax the ACID properties to some extent for performance reasons, such as throughput and concurrency.
IBM WebSphere MQ products are able to denote certain data items (messages) as persistent, and others as non-persistent. The persistence manager and its persistence store are used to guarantee those data items classified as persistent. A problem arises where a system permits transactions including operations spanning multiple levels of reliability over and above persistent and non-persistent. In other words, a system may permit varying degrees of persistence. It is known, for example, to denote a message as semi-persistent. This means that such a message may be lost upon system failure but not at controlled shutdown. A co-pending patent application Ser. No. 11/260,857 to the present assignee also deals with this subject.